IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた

IAM ロールはお面のようなもの　IAM ロールはお面のようなもの　IAM ロールはお面のようなもの

#IAM Role

#図解

#AWS IAM

#AWS

千葉幸宏（チバユキ）

2020.12.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンバンハ、千葉（幸）です。

皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。

私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。

ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。

そこで出来上がったのが以下です。

PassRoleAssumeRole

間違えました。以下です。

PassRoleAssumeRole2

あ、でもやっぱり忘れづらいのはこちらかもしれませんね。

PassRoleAssumeRole

どうですか？もう忘れられなくなりましたね？

先にまとめ

IAM ロールには以下ポリシーを設定できる
- アイデンティティベースポリシー
- Permissions boundary
- 信頼ポリシー
AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要
- PassRole は独立したアクションではない
AsumeRole することで IAM ロールに設定された権限を引き受けることができる
- AssumeRole を実行する際には STS を介している
- AssumeRole を行うのは IAM ユーザーだけではない
- AssumeRole は重ね掛けできる

IAM ロールとはお面のようなものである

皆さんご存知かと思いますが、 IAM ロールはお面のようなものです。

間違えました。皆さんご存知ではないと思いますが、私は「 IAM ロールとはお面のようなものである」という風説を流布しようとしています。

AWS のアイコンでは IAM ロールはヘルメットで表現されていますが、日本情緒あふれるお面の方が好きです。あと、被って力を得るならお面の方が気分が出ますよね。

IAM ロール自身はアクションを実行できない

IAM ロールには権限（【力】）を与えることができますが、 IAM ロール自身がその権限を行使することはありません。

IAMRole1

IAM ロールことお面を被る人がいて初めて、その力を使えるようになります。

IAMRole2

IAM ロールと 3つのポリシー

「 ちょっと IAM ロールに設定されたポリシーを確認して」と言われたら皆さんはどこを確認しますか？

（以前の私なら「【ポリシー】とは具体的に何を指していますか。指示が曖昧なため対応できません。」と答えていましたが、流石にいまはいい大人なのでそんなことはしません。）

確認箇所としてアイデンティティベースポリシーを想像する方が多いかと思いますが、IAM ロールに「設定」できるポリシーは以下の 3 つがあります。

アイデンティティベースポリシー
Permissions boundary
信頼ポリシー

3 つも設定できるのは IAM ロールだけです。こんなにも多くのポリシーをもらえる IAM ロールは特別な存在なんだと私は感じました。

IAMRole3

アイデンティティベースポリシーと Permissions boundary は以下から確認できます。

信頼ポリシーはここから確認できます。ちなみに信頼ポリシーは、分類としてはリソースベースポリシーというものに属します。

IAM ロールの力を得る際に一時的に設定できるセッションポリシーという概念もあるのですが、今日のところは忘れておきましょう。

IAM ロールの力を得る

お面を被って IAM ロールの力を得ると、その IAM ロールが持っていた力を引き継ぎます。一方で、元々持っていた力は失われます。

IAMRole4

同じ IAM ロールを被ったエンティティは同じ権限を持ちます。エンティティは IAM ユーザーに限らず、 AWS サービス、外部 Idp である場合もあります。

IAMRole5

力を行使できるのは人間だけではない……覚えておいてください。

PassRole とは

PassRole は、 AWS サービスに IAM ロールをパスするための権限を表します。 PassRole という独立したアクションがあるわけではありません。

以下表でも、「アクセス許可のみ」の記述がありますね。

Identity and Access Management のアクション、リソース、および条件キー - AWS Identity and Access Management

AWS_Identity_and_Access_Management

PassRole が無いばっかりにインスタンス 1 台すら立ち上げられない

PassRole が必要となる代表的なケースとして、 EC2 インスタンスの作成があります。

多くの場合、EC2 インスタンスには初めからロールを設定した状態で作成を行うでしょう。

ここで、操作ユーザーにAWS 管理ポリシーAmazonEC2FullAccessと参照権限のみが与えられている状況を考えます。 IAM に関する権限は限られたユーザーにのみ割り当てる、というのはよくあるケースです。

AmazonEC2FullAccessにはiam:PassRoleの許可が含まれていません。その状態で IAM ロールをアタッチした EC2 インスタンスを作成しようとすると、最後のステップでエラーが発生します。

You are not authorized to perform this operation. Encoded authorization failure message:

以下のページの手順に従いエラーメッセージをデコードすると、メッセージに"action":"iam:PassRole"が含まれていることを確認できます。

EC2 インスタンスの起動時の UnauthorizedOperation エラーを解決する

他のアクションに付随して PassRole が必要となる

このケースにおいては EC2 インスタンスの作成を行うec2:RunInstancesと一緒に iam:PassRoleというアクションが呼び出されており、それを実行するための権限が必要となります。

IAMRole6

新規作成時だけでなく、既存の EC2 インスタンスのロール設定を変更する際にも PassRole は必要です。そして EC2 インスタンス以外にも IAM ロールを受け渡すことができる AWS サービスやそのリソースは多数存在します。

「人が使う IAM ロールを操作する権限は不要だが、 PassRole が必要となる」というケースは多々あります。権限設計の際には PassRole をどうするかを意識しておくとよいでしょう。

PassRole で渡せるロールやサービスを制限することもできます。

ちなみに IAM ロールを被ったユーザーが PassRole することもできます。

IAMRole7

AssumeRole とは

AssumeRole は、IAM ロールを引き受けるためのアクションを表します。ここまで「 IAM ロールのお面を被る」と表現してきたものは、概ね AssumeRole のことを表しています。

ちなみに AssumeRole のサービスプレフィックスはiamではなくstsです。iam:AssumeRoleではなくsts:AssumeRoleです。

AWS Security Token Service のアクション、リソース、および条件キー - AWS Identity and Access Management

AWS_Identity_and_Access_Management-8469693

先ほど確認した IAM ロールの信頼ポリシーにおいても、アクションとしてsts:AssumeRoleが許可されています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

IAM ロールのお面を直接被れるわけでは無い

当然のように「 IAM ロールのお面を被る」と表現してきましたが、実際には IAM ロールを被ることはできません。もう少し実態に近い表現をすると、「 STS を通じて祈りを捧げ、 IAM ロールと同じ力を一時的に得る」という挙動となります。

力を得るために媒介を必要とする、よくある話ですね。

IAMRole8

ユーザーが sts:AssumeRoleを行うと、STS は両者のポリシーを評価して AssumeRole を行って問題ないかを確認し、問題なければユーザーに以下の3つを与えます。

アクセスキーID
シークレットアクセスキー
セッショントークン

上記により、ユーザーは IAM ロールが持っていた力を一時的に使用できるようになります。

スイッチロールをする時も AssumeRole をしている

マネジメントコンソール上でロールを切り替えて作業する（スイッチロール）、という操作を行っている方は多いかと思います。その裏側では、AssumeRole が行われています。

SwitchRole

以下は CloudTrail に記録された SwitchRole イベントのイメージです。

スイッチ元のアカウントが999999999999、スイッチ先のアカウントが000000000000です。

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "xxxxxxxxxH732QEGJXBGU:セッション名（ユーザー名）",
        "arn": "arn:aws:sts::000000000000:assumed-role/スイッチ先ロール名/セッション名（ユーザー名）",
        "accountId": "000000000000"
    },
    "eventTime": "2020-12-20T11:55:50Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "SwitchRole",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "202.xx.xxx.xx",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36",
    "requestParameters": null,
    "responseElements": {
        "SwitchRole": "Success"
    },
    "additionalEventData": {
        "SwitchFrom": "arn:aws:iam::999999999999:user/ユーザー名",
        "RedirectTo": "https://ap-northeast-1.console.aws.amazon.com/console/home?region=ap-northeast-1#"
    },
    "eventID": "xxxxxxxx-adc1-496d-9252-d59a3da0b7c2",
    "readOnly": false,
    "eventType": "AwsConsoleSignIn",
    "managementEvent": true,
    "eventCategory": "Management",
    "recipientAccountId": "000000000000"
}

マネジメントコンソールの操作で明示的に AssumeRole を行うことはありませんが、スイッチした時点で AssumeRole 後のユーザーが記録されていることが分かります。

AssumeRole を行う際は、そのセッションごとにセッション名が付与されます。スイッチロールの際は、自動的に「スイッチ元のユーザー名」がセッション名として設定されます。